Журнал операций в 389 DS при переключении на системную учетную запись в серверной части ALD Pro

Начиная с версии 3.2.0 ALD Pro на каждом контроллере домена (далее – КД) ведется отдельный журнал ALD Pro. В него записываются только те операции, которые были инициированы через API ALD Pro и выполнены в контексте системной учетной записи. Такие операции требуются, когда у обычной учетной записи пользователя недостаточно прав.

Основные особенности журнала операций:

  1. Журнал создается и начинает наполняться на каждом контроллере домена автоматически при установке с нуля ALD Pro версии 3.2.0 или обновлении до ALD Pro 3.2.0;

  2. Журнал ведется в файле /var/log/aldpro/sysaccounts_requsts.log;

  3. Права на данный журнал полностью аналогичны остальным файлам в каталоге /var/log/aldpro (владелец и группа ipaapi, права на файл в формате UGO - 640);

  4. Для журнала при установке серверной части ALD Pro автоматически создается отдельная конфигурация для утилиты logrotate.

    Особенности утилиты logrotate:

    • максимальный размер файла журнала – 100 Мб;

    • максимальное количество журналов – 10;

    • все хранящиеся журналы, кроме двух последних, автоматически сжимаются.

    Файл конфигурации для утилиты logrotate находится по пути /etc/logrotate.d/aldpro-mp-core.

  5. Включением и выключением записи в журнал для конкретного экземпляра серверной части ALD Pro на КД можно управлять с помощью параметра ENABLE_SYSACCOUNTS_REQUESTS_LOG.

    Для отключения ведения журнала необходимо выполнить следующие действия (журнал по умолчанию ведется на каждом КД):

    • добавить строку ENABLE_SYSACCOUNTS_REQUESTS_LOG=FALSE в файл /etc/aldpro/core.env;

    • выполнить перезапуск сервиса apache2 с помощью команды:

    sudo apachectl -k graceful

    или с помощью команды:

    sudo systemctl restart apache2

    После выполнения этих действий, операции в журнал записываться не будут.

    Для включения записи в журнал необходимо:

    • удалить из файла /etc/aldpro/core.env строку ENABLE_SYSACCOUNTS_REQUESTS_LOG=FALSE;

    • выполнить перезапуск сервиса apache2.

  6. В журнале /var/log/aldpro/sysaccounts_requsts.log для каждой отдельной операции (поиска, изменения, создания или удаления) создаются отдельные json-объекты с определенной структурой. Разделителями между парами «ключ-значение» в одном объекте являются пробелы. Также пробел ставится перед значением.

Пример json-объекта из файла журнала

{"principal": "admin@ALD.PRO.RU", "req_time": "20260303145146", "op": "modify", "dn": "cn=5a92466a-d1ec-404a-8544-2bf23e7c9b11,cn=gpolicy,cn=gp,dc=ald,dc=pro,dc=ru", "sysaccount": "uid=saltstackservice_dc01,cn=sysaccounts,cn=etc,dc=ald,dc=pro,dc=ru", "request_uri": "/ad/api/ds/group-policies/5a92466a-d1ec-404a-8544-2bf23e7c9b11/organizational-units", "request_method": "POST", "mod_wsgi_request_id": "IkbfU345raI", "remote_addr": "192.168.2.1", "remote_port": "56476", "result": "0", "resp_time": "20260303145146"}

где:

  • "req_time" – время, когда посылается запрос от системной УЗ в формате YYYYMMDDhhmmss, например 20250930101420 (local time);

  • "resp_time" – время, когда на серверной части получен ответ от 389 DS в формате YYYYMMDDhhmmss, например 20250930101545 (local time);

  • "result" – код результата выполнения операции, который должен быть равен нулю (0) в случае успешной операции или содержать строку ошибки, которую вернул 389 DS;

  • "principal" – имя принципала, который инициировал действие (вызов API ALD Pro через портал управления или иным способом);

  • "sysaccount" – имя (dn в 389 DS) системной УЗ, от которой будет выполняться операция в 389 DS;

  • "op" – тип операции, который будет выполняться (может содержать содержать 4 значения: add для операций добавления записи, delete для операций удаления записи, modify для операций модификации и srch для операций поиска записей в 389 DS);

  • "dn" – тот dn, к которому совершается операция;

  • "request_uri" – полный путь запроса (путь для вызова API);

  • "request_method" – HTTP-метод, использованный в запросе, он определяет тип запрошенного действия;

  • "mod_wsgi_request_id" – уникальный идентификатор запроса, генерируемый модулем mod_wsgi;

  • "remote_addr" – IP-адрес клиента (пользователя), который установил соединение с сервером (адрес последнего proxy-сервера в сетевом маршруте до клиента);

  • "remote_port" – номер порта на устройстве клиента, с которого был отправлен запрос.

Для запросов с операцией поиска ("op":"srch") дополнительно добавляются следующие ключи:

  • "scope" – значение глубины поиска для запроса типа srch (целое число);

  • "filter" – строка фильтра для поиска для запроса типа srch (может быть null);

  • "attrs" - список атрибутов, значения которых запрашиваются в запросе типа srch.

Если запрос имеет тип, отличный от srch, то ключи scope, filter и attrs не создаются в json-объекте.

Пример json-объекта из файла журнала, в котором записан запроса на поиск информации (тип srch):

{"principal": "admin@ALD.PRO.RU", "req_time": "20260303145146", "op": "srch", "dn": "cn=5a92466a-d1ec-404a-8544-2bf23e7c9b11,cn=gpolicy,cn=gp,dc=ald,dc=pro,dc=ru", "sysaccount": "uid=saltstackservice_dc01,cn=sysaccounts,cn=etc,dc=ald,dc=pro,dc=ru", "request_uri": "/ad/api/ds/group-policies/5a92466a-d1ec-404a-8544-2bf23e7c9b11/organizational-units", "request_method": "POST", "mod_wsgi_request_id": "IkbfU719raI", "remote_addr": "192.168.2.1", "remote_port": "56476", "scope": 0, "filter": null, "attrs": ["modifyTimestamp", "rbtapolicyversion", "primarykey", "member", "memberOf", "aldproPolicyAllowFilterEnabled", "cn", "displayName", "entryid", "aldproChangesAuthtor", "fullname", "createTimestamp", "description", "aldproPolicyDenyFilterEnabled", "parentid", "objectClass"], "result": "0", "resp_time": "20260303145146"}

В примере показано, что происходит запрос на поиск и получение информации по набору атрибутов, перечисленных в массиве значений для ключа "attrs" у записи с dn, равным "cn=5a92466a-d1ec-404a-8544-2bf23e7c9b11,cn=gpolicy,cn=gp,dc=ald,dc=pro,dc=ru" и происходит это по запросу пользователя c uid=admin со сменой учетной записи на uid=saltstackservice_dc01,cn=sysaccounts,cn=etc,dc=ald,dc=pro,dc=ru. При этом был вызван метод POST по пути /ad/api/ds/group-policies/5a92466a-d1ec-404a-8544-2bf23e7c9b11/organizational-units.

  1. Если при запуске приложения (серверной части ALD Pro) невозможно осуществить инициализацию записи в журнал /var/log/aldpro/sysaccounts_requsts.log по любой из причин, то серверная часть ALD Pro не стартует. В журнал syslog записывается ошибка (код ERROR) с текстом: «Произошла следующая ошибка при запуске бэкенда ALD Pro: {текст_ошибки}».

Если журнал /var/log/aldpro/sysaccounts_requsts.log станет недоступен для записи в процессе работы приложения серверной части ALD Pro, то приложение продолжит свою работу, но при любой неуспешной попытке записи информации в журнал /var/log/aldpro/sysaccounts_requsts.log будет предпринята попытка записи сообщения об ошибке (код ERROR) в журнал syslog с текстом «Невозможно выполнить запись в журнал /var/log/aldpro/sysaccounts_requsts.log. Ошибка: {текст_ошибки}».